You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On both WD53 appliances in my local setup, an unsuccessful initial certificate
handshake can stop after HelloVerifyRequest. The appliance retains that
half-open IoTivity peer on the client UDP tuple, and an immediate clean retry
can remain silent even though the endpoint is otherwise healthy.
The working recovery path sends the standard epoch-zero fatal handshake_failure alert for that exact incomplete peer, waits outside the
transport, and then retries from the same fixed source port. This PR adds the
transport half only; the package does not choose the retry delay or perform a
retry.
What changes
adds opt-in connect(cleanup_hvr_peer=True) for sessions using an actual SamsungServerProfile and a fixed non-zero local_port;
records at most 32 datagrams/records as counters and one 13-byte outbound
header, never handshake payloads;
requires two complete epoch-zero ClientHellos, including one after an HVR;
requires every received record to contain only complete epoch-zero
HelloVerifyRequest messages;
rejects malformed, fragmented, mixed, non-HVR, non-ClientHello, or oversized
transcripts without sending an alert;
sends at most one nonblocking cleanup alert after the handshake deadline;
and
raises HandshakePeerCleanupError, a SessionTimeoutError subclass, only
when the complete alert datagram was handed to the UDP socket.
An ordinary timeout remains SessionTimeoutError. Cancellation, OpenSSL
failure, socket I/O failure, an inexact transcript, or cleanup-send failure do
not enter the caller's cleanup/retry path.
Validation
714 tests pass on Python 3.14
focused coverage checks the exact alert bytes and record sequence, transcript
ordering, metadata bounds, malformed and mixed records, cancellation, send
failure, provider/port preconditions, and no automatic retry
the shared handshake driver reports only records successfully sent
This is stacked on #76 and currently includes that commit in the GitHub diff.
Please merge #76 first; this PR then reduces to commit 92ec459. #74 remains
independent. The final PY-18 API/documentation PR will stack on this one.
I read the cleanup mechanism back against the pinned RT-OCF tree I keep locally (Samsung/RT-OCF, last pushed 2023-04-07) and it holds. rt_ssl_error_check (messaging/transport/rt_ssl.c:373) frees the peer with ssl_remove_peer_from_list on any non-exempt negative return, and it suppresses the return alert for both MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE and MBEDTLS_ERR_SSL_BAD_HS_CLIENT_HELLO. The peer goes and the server stays quiet.
One detail you may find useful: in that tree the return code is BAD_HS_CLIENT_HELLO. While the server sits in MBEDTLS_SSL_CLIENT_HELLO it parses the record header inside ssl_parse_client_hello (ssl_srv.c:952), which rejects every content type other than handshake and returns there, ahead of the alert path. Same outcome by a different route.
That is a 2023 source reading, so your WD53s remain the real evidence. The code stands as written: the alert is the standards-correct thing to send either way.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements the second half of #75.
Why
On both WD53 appliances in my local setup, an unsuccessful initial certificate
handshake can stop after HelloVerifyRequest. The appliance retains that
half-open IoTivity peer on the client UDP tuple, and an immediate clean retry
can remain silent even though the endpoint is otherwise healthy.
The working recovery path sends the standard epoch-zero fatal
handshake_failurealert for that exact incomplete peer, waits outside thetransport, and then retries from the same fixed source port. This PR adds the
transport half only; the package does not choose the retry delay or perform a
retry.
What changes
connect(cleanup_hvr_peer=True)for sessions using an actualSamsungServerProfileand a fixed non-zerolocal_port;header, never handshake payloads;
HelloVerifyRequest messages;
transcripts without sending an alert;
and
HandshakePeerCleanupError, aSessionTimeoutErrorsubclass, onlywhen the complete alert datagram was handed to the UDP socket.
An ordinary timeout remains
SessionTimeoutError. Cancellation, OpenSSLfailure, socket I/O failure, an inexact transcript, or cleanup-send failure do
not enter the caller's cleanup/retry path.
Validation
ordering, metadata bounds, malformed and mixed records, cancellation, send
failure, provider/port preconditions, and no automatic retry
Merge order
This is stacked on #76 and currently includes that commit in the GitHub diff.
Please merge #76 first; this PR then reduces to commit
92ec459. #74 remainsindependent. The final PY-18 API/documentation PR will stack on this one.